IRIX Development Foundation for IRIX 6.4

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Development Foundation for IRIX 6.4 / SGI IRIX 6.4 Development Foundation.iso / docs6.4 / relnotes / WorkShop / ch3.z / ch3

Wrap

Text File | 1997-09-11 | 38KB | 925 lines

- 1 - 3. _C_h_a_n_g_e_s__a_n_d__A_d_d_i_t_i_o_n_s These are the changes from WorkShop 2.6.4: +o Compiler based "new" expression evaluator for n32 C++. This gives calls to virtual functions, member references without needing "this->" and other C++ features. +o Support for -n32 "-gslim" compilations, which reduce the size of the symbolic debug information for C++ programs. +o F90 expression evaluation improvements. +o Irix 6.5 pthreads support. 3.1 _N_e_w__F_e_a_t_u_r_e_s__i_n__T_h_i_s__R_e_l_e_a_s_e +o WorkShop now supports the debugging of applications that use pthreads. The changes are the addition of the "showthread" command and the addition of an optional "thread" argument to the "where" command. In order to debug pthreads programs, WorkShop's default breakpoint behavior should be set in one of the following two ways. The first is to set the "adaMode" resource in your .Xdefaults file. This can be done with the following line: *adaMode: True This sets the source view mode to control all running processes in the share group and sets the Group Trap and Stop All toggles in the Traps pulldown. The second way to change the breakpoint behavior is to do the following: First, use the rightmouse over the Run, Continue or Stop buttons (whichever is active) to invoke the Process Control Mode popup and make the "All Processes" selection. Next, invoke the Traps pulldown and set the Group Trap default and the Stop All trap default. The showthread command provides status information about the threads in your program. In one session, you cannot debug more than one program that uses threads. The syntax of the "showthread" command is: showthread [full] - 2 - showthread [full] [thread] {number | all} The first form prints brief status information about the current thread. If the full qualifier is included, prints full status information. The second form prints brief status information about the thread identified by number or all threads associated with the debug session. If the full qualifier is included, prints full status information. The thread qualifier does not affect the output. The "where" command has been extended so that thread callstacks can be printed: where [thread thread-id] A thread's id is obtained from the first column of the output of the "showthread" command. +o WorkShop now provides a form of breakpoint that fires when a C++ exception is raised. The "stop exception" command is used to set such a breakpoint. You can add a conditional expression to an exception breakpoint by using the trap manager window. However, the context in which the expression is evaluated is not that of the throw; the context is the exception handling code of the C++ runtime library. Hence, only global variables have unambiguous interpretation in the if clause. The syntax for setting an exception breakpoint is: stop exception {all | item} stop exception unexpected {[all] | [item [, item] ]} The first form stops on all C++ exceptions, or exceptions that throw the base type item. The second form stops on all C++ exceptions that have either no handler or are caught by an "unexpected" handler. If you specify item, stops on exceptions that throw the base type item. Do not include complex expressions involving operators such as * and & in your type specification for an exception breakpoint. Note, however, that if you create an exception breakpoint with a specific base type, you will also stop your program on throws of pointer, - 3 - reference, const and volatile types. For example: (cvd) stop exception char Your program will stop on throws of type char, char *, char&, const char&, volatile char*, and so forth. 3.2 _F_e_a_t_u_r_e_s__a_d_d_e_d__i_n__P_r_i_o_r__R_e_l_e_a_s_e_s In WorkShop 2.6, the Static Analyzer can analyze Fortran 90 source code in its accurate parser mode. Fortran 90 sources can also be analyzed in the Static Anayzer's less-accurate scanner mode. RRRReeeeqqqquuuuiiiirrrreeeemmmmeeeennnnttttssss: to use the Static Analyzer on Fortran 90, you must have the Fortran 90 compiler installed. 3.2.1 _C_h_a_n_g_e_s__i_n__t_h_e__I_n_t_e_r_f_a_c_e +o The "Host" text field has been removed. +o The "Data" menu has been removed and replaced with the pop-up expression evaluator. Pop-up expression evaluation is activated by right-clicking in the source area in MainView and selecting either "Click to Evaluate" or "Auto Evaluate" in the pop-up menu. "Click to Evaluate" means that when the process is stopped, if you left-click on a symbol the current value of that symbol will be displayed in a small pop- up window near the source. "Auto Evaluate" means that you don't have to click on a symbol to see its value, simply move the mouse over the symbol and hesitate; the value will appear as though the mouse had been clicked. Selecting an expression in either mode will cause it to be evaluated. You can get rid of the pop-up value by moving the mouse out of the source area or by touching the pop-up value with the mouse cursor. +o The "Performance Panel" under the "Admin" menu has been removed and replaced with the "Perf" menu on the top- level menubar. There are three entries under this menu: "Select Task" allows you to specify what performance data to gather, "Examine Results" allows you to launch the Performance Analyzer, and "Configs" brings up the configuration dialog specifying control information that you typically shouldn't have to change. The option menu just above the "Run" button tells you when you are in debug, performance, or purify mode and allows you to turn those modes on and off. (Purify mode is only available if Purify from Pure Software is installed on your system.) - 4 - +o When a performance experiment is finished, cvperf is normally started immediately. This feature may be disabled using a toggle in the "Configs..." dialog. +o When recording performance experiments, a new option allows you to follow _f_o_r_k'd processes or not; by default, experiments will follow. +o The source view in the debugger will be shared with a Performance Analyzer, and performance annotations will appear in it. Similarly, it will be shared with WorkShop Pro MPF, and loop annotations will appear. 3.2.2 _G_e_n_e_r_a_l__C_h_a_n_g_e_s__s_i_n_c_e__2_._4 WorkShop now supports debugging and analyzing 64-bit executables built using either the MIPS3 or MIPS4 ABI (application binary interface) protocols (that is, programs that were built with the -mips3 or -mips4 flags) in addition to 32-bit executables. The ability to support 64-bit executables has three general consequences: +o Any WorkShop view that can display addresses (pointers) can display the 64-bit addresses. +o Any WorkShop view that can display registers shows the new configurations of registers and precisions available in MIPS3 and MIPS4. The details are discussed in the WorkShop Debugger changes section. +o Any WorkShop view that displays disassembled source code displays the 64-bit instruction set as well as the 64-bit addresses. +o WorkShop user authentication has been changed to conform to the .rhosts-based model used by rcp and rsh. This could break some remote debugging scenarios. See the _c_v_c_o_n_n_e_c_t(1m) and _r_h_o_s_t_s(4) man pages for further details. +o The _W_o_r_k_S_h_o_p _O_v_e_r_v_i_e_w book was added. This purpose of this book is to provide a comprehensive overview of the WorkShop features and to provide pointers of where to look in the manuals for help. 3.3 _C_h_a_n_g_e_s__i_n__t_h_e__D_e_b_u_g_g_e_r +o Signals are trapped differently by recent versions of _c_v_d (versions 2.4 and later) than by earlier versions. If a signal is received that may lead to termination of the process, earlier versions of _c_v_d would always trap - 5 - the signal. (See _s_i_g_n_a_l(5) for the list of signals that may lead to process termination). In newer versions of WorkShop, _c_v_d's default behavior is to trap such a signal only if the process has not registered a handler for the signal. For example, if the action on SIGSEGV is SIG_DFL and the process receives a SIGSEGV, _c_v_d will stop the process. On the other hand, if the action on SIGSEGV is a handler function and the process receives a SIGSEGV, _c_v_d will not stop the process and SIGSEGV will be delivered to the process. _c_v_d's default treatment of such signals can be overridden. The user can choose for a trap on a signal either to stop the process whenever the signal is received, or to stop the process only when there is no handler registered for the signal. The command _c_a_t_c_h <_s_i_g_n_a_l> will cause _c_v_d to always stop the process when <signal> is received. The command _c_a_t_c_h _u_n_h_a_n_d_l_e_d <_s_i_g_n_a_l> will cause _c_v_d to stop the process when <signal> is received only if there is no handler registered for <signal>. The command _c_a_t_c_h will show which signals are being trapped by _c_v_d; the signals that are only trapped when there is no registered handler are displayed as <signal> (when unhandled). Those users who prefer to have _c_v_d unconditionally trap signals that may cause process termination may create a ._c_v_d_r_c file in the their home directory and include the following lines. This will cause versions 2.4 and later of _c_v_d to behave just as earlier versions with regard to the default trapping of signals. catch SIGINT catch SIGQUIT catch SIGILL catch SIGTRAP catch SIGABRT catch SIGEMT catch SIGFPE catch SIGBUS catch SIGSEGV catch SIGSYS catch SIGPIPE catch SIGALRM catch SIGTERM catch SIGUSR1 catch SIGUSR2 catch SIGPOLL catch SIGVTALRM - 6 - catch SIGPROF catch SIGXCPU catch SIGXFSZ +o The debugger's "Remap Paths" feature can now be used to map in source files whose name conflicts with a file in the current working directory. As a result of this change, if you have sources compiled "-g" in other directories, and similarly-named sources in ".", you will not get the "." ones automatically. This is a change from prior versions of WorkShop, where the sources in "." were used unconditionally. To force the debugger to use the sources in "." in these circumstances, use Path Remapping to remap the path named in the "File not in executable" dialog to "." +o The Debugger lets you switch back and forth between sessions debugging 32-bit and 64-bit executables. +o In Main View, the PC address displays as a 64-bit address for MIPS3 and MIPS4 executables. The PC address appears in the _S_t_a_t_u_s field at the top of the window and in the Debugger command line at the bottom of the window. +o The _R_e_s_u_l_t column in Expression View displays 64-bit addresses for MIPS3 and MIPS4 executables when you select the "Address Of" menu item in the Format menu. +o The _R_e_s_u_l_t column in Variable Browser displays 64-bit addresses for MIPS3 and MIPS4 executables when you select the "Address Of" menu item in the Format menu. +o The _A_d_d_r_e_s_s field and address column display in Memory View displays 64-bit addresses for MIPS3 and MIPS4 executables. +o The source display area in Disassembly View now displays the 64-bit instruction set and the 64-bit addresses for MIPS3 and MIPS4. The address fields in the "Address..." and "Function..." dialog boxes accessed from the Disassemble menu can accommodate 64- bit addresses for MIPS3 and MIPS4 executables. +o Register View has changed the most radically of any of the Debugger views. Here's a comparison of Register View running a MIPS1 executable versus a MIPS4 executable: - Register View has 32 32-bit general purpose registers for MIPS1 executables and 32 64-bit - 7 - general purpose registers for MIPS4. - Register View has five 32-bit special purpose registers for MIPS1. For MIPS4 executables, there are four 64-bit special registers and one 32-bit register (_f_p_s_c_r). - Register View has 16 32-bit floating point registers for MIPS1 executables and 32 32-bit floating point registers for MIPS4. - Register View has 16 64-bit double-precision registers for MIPS1 executables and 32 64-bit double-precision registers for MIPS4. The _p_r_i_n_t_r_e_g_s command on the Debugger command line will print out the register values for the MIPS1 and MIPS4 ABIs as well. +o The following assignment operators for C expressions are now supported in Expression View and the Expression Evaluator dialog box: = += -= /= %= >>= <<= &= ^= |= 0hese should be used with caution to avoid inadvertently modifying a variable while stepping through a program. the name of the .Counts file as an argument. 3.4 _C_h_a_n_g_e_s__i_n__P_e_r_f__T_o_o_l_s +o The performance tools now work on both 32- and 64-bit non-shared executables with two exceptions: - You cannot perform malloc/free tracing on non- shared executables. The _l_i_b_e_x_c._a library is not available. - A new view, the Butterfly View, is available. It is a textual alternative to the Callgraph View that shows the current selected node in the center, with scrolled lists of callers (parents) above it, and callees (children) below it. It has the following features: - Each entry in the list shows the same information shown in the main function list, along with an attribution percentage of whichever data item the main function list is sorted by. For the selected function itself, - 8 - the attribution percentage is the percentage of the function's Inclusive <whatever> that comes from the function's Exclusive <whatever>, and the attribution percentage of the children represent the percentage of the Inclusive <whatever> of the selected node that came from that child. For the parents, the attribution percentage is that percentage of the selected function's inclusive <whatever> that is attributed to the particular parent function. Note that for some sort orders, (e.g., address, alphabetic, calls, instruction counts, ...) there either is no corresponding data to propagate along the arcs, or we do not keep the data, because it takes too much memory; for those data types, the attribution percentages are all shown as "-". Attribution percentages shown as "0. %" mean a true zero, while those shown as "0.0%" mean a value > 0, but < 0.1%. - A single click on any line in the parent or child lists will select the node corresponding to that line, and refill the view with data based on the new selected function. Similarly, a single click in the main function list, or any node in the graph will refill the Butterfly View. - There are two controls on the "Config" menu of the butterfly view. "Show Zero Arcs" determines whether or not zero-arcs, that is arcs that were never traversed, are shown. Zero arcs will have their attribution percentages shown as "0. %". "Show All Arcs Individually" determines whether a single arc is shown between two nodes, with the data summed across all callsites from the parent to the child, or whether each individual arc (callsite) is shown. If it is selected, the function name of each child has a PC value appended to it corresponding to the address of the individual call to that child function from the selected function; likewise, the parent name has the address of its call to the selected function appended. (The PC address is shown rather than the line number because it is very expensive to look up the linenumber for each call site. You can see which call site is which by invoking the source for the appropriate function.) - 9 - - The source of the selected function can be invoked by the "Source" button just above the line for the selected function. There is no control that directly allows invocation of source from a line in either the parent or the child list. - Performance experiments on executables that dynamically link many DSOs can be expensive, because we currently record a sample at every invocation of _d_l_o_p_e_n. We believe it is preferable to not take a sample at all such calls, but have not tested it sufficiently to make it the default. To record experiments without such samples, you need to set: _c_v_m_o_n*_n_o_S_a_m_p_l_e_O_n_D_l_o_p_e_n to TRUE in your ._X_d_e_f_a_u_l_t_s file. - A new graph pushbutton, _S_h_o_w _I_m_p_o_r_t_a_n_t _P_a_r_e_n_t_s, is available. It will show those callers of a given function where usage exceeds a threshold. - The Performance Analyzer now can show information about working sets for instructions for Ideal-time experiments. The new Working Set View will show a list of the program and its DSOs in the program, and, for a selected DSO, show the page layout and utilization. - A new tool, _c_v_c_o_r_d, the Cord Analyzer is available for producing cord feedback files to optimize instruction working sets for programs. It takes working set information from one or more experiments and/or different caliper settings, and computes an optimized layout to improve working set behavior. Although the tool works on both 32- and 64-bit programs, at this time _c_o_r_d itself only works on 32-bit executables and DSOs. See the _c_v_c_o_r_d man page for further information. - The Performance Analyzer can now obtain performance data equivalent to _p_i_x_i_e and _p_i_x_s_t_a_t_s. This lets you see metrics based on the time that instructions were available for processing but could not be completed for some reason, such as branch, function unit, or operand delays. To capture _p_i_x_i_e data, you select the task "Get Ideal Time (pixie) per function & source line" from the Task menu in the Performance Panel. (This task was formerly called "Get Ideal Time per - 10 - function & source line".) The new version of the task enables you to show the following types of performance data in your experiments: - Inclusive percentage time - the percentage of time that instructions in this function (and any called functions) were available for processing but could not be processed. - Exclusive percentage time - the percentage of time that instructions in this function (excluding any calls) were available for processing but could not be processed. - Inclusive cycles - the number of elapsed cycles in this function, line of code, or instruction (including any calls). - Exclusive cycles - the number of elapsed cycles in this function, line of code, or instruction (excluding any calls). - Instruction coverage - the percentage of the instructions within each function that were actually executed. In the disassembled source, branch-taken counts are displayed. Branch-taken counts show the number of times that each conditional branch was taken. - Pixstats/Cycles-per instruction - the ratio of cycles to instructions. In a classic RISC machine, the Pixstats/Cycles-per instruction ratio would be 1.0. If the ratio is much greater than 1.0, you should check the disassembled source to determine the reasons for this inefficiency. Clicking the Disassembled Source button in the Performance Analyzer displays the disassembled code in a Source View window with a special three-part annotation. A yellow bar spanning the top of three columns in this annotation indicates the first instruction in each basic block. The first column labelled _C_l_o_c_k in the annotation displays the clock number in which the instruction issues relative to the start of a basic block. If you see clock numbers replaced by ditto marks ("), it means that multiple instructions were issued in the same cycle. The second column is labelled _S_t_a_l_l and shows how many clocks elapsed during the stall before the instruction was issued. The - 11 - third column labelled _W_h_y shows the reason for the stall. There are three possibilities: +o B - branch delay +o F - function unit delay +o O - operand hasn't arrived yet - The Performance Analyzer also provides a new view, Malloc Error View, that lets you focus on _m_a_l_l_o_c errors without having to sort through legitimate _m_a_l_l_o_c operations. Malloc Error View is available when you perform the "Find Memory Leaks" task. It takes the same form as Malloc View--the difference is that where Malloc View displays all _m_a_l_l_o_c_s in its list area (the upper pane), Malloc Error View displays only _m_a_l_l_o_c_s or _f_r_e_e_s that caused errors, identifying the cause of the problem and how many times it occurred. Malloc Error View replaces some of the functionality of Heap View. When you run a "Find Memory Leaks" experiment and the Performance Analyzer detects a _m_a_l_l_o_c error, a dialog box will display recommending that you use Malloc Error View to analyze the results. - The "Find Memory Leaks Task" task has four associated performance metrics available. The leak counts were previously on by default--the malloc counts are now turned on as well. The metrics are: - Inclusive Bytes Leaked - the number of bytes leaked from this function (including any called functions). This metric can be turned on for arcs as well as functions. - Exclusive Bytes Leaked - the number of bytes leaked from this function (excluding any called functions). - Inclusive Bytes malloc'ed - the number of bytes _m_a_l_l_o_c'_e_d from this function (including any called functions). This metric can be turned on for arcs as well as functions. - Exclusive Bytes malloc'ed - the number of bytes _m_a_l_l_o_c'_e_d from this function (excluding any called functions). - 12 - - There is a new task called "Get PC Sampling Times". It has no new functionality. It simply lets you perform statistical profiling with fine grained usage sampling at 1-second intervals without capturing any other performance data. It works on 32- and 64-bit processes and under IRIX 6.2. - The "Determine bottlenecks, identify phases" task and the "Get Total Time per function & source line" task both capture Call Stack Profiling data every 100 msec. by default. - I/O tracing has been incorporated into Syscall Tracing. When you perform Syscall tracing experiments, you can now get _r_e_a_d and _w_r_i_t_e counts and can display I/O View. - If you prefer to sort by exclusive rather than inclusive data by default, you need to set _c_v_p_e_r_f*_e_m_p_h_a_s_i_z_e_E_x_c_l_u_s_i_v_e to TRUE in your ._X_d_e_f_a_u_l_t_s file. - The following environment variables are available for "Find Memory Leaks" experiments: - _M_A_L_L_O_C__V_E_R_B_O_S_E - _M_A_L_L_O_C__T_R_A_C_I_N_G - _M_A_L_L_O_C__F_A_S_T_C_H_K - _M_A_L_L_O_C__M_A_X_M_A_L_L_O_C - _M_A_L_L_O_C__N_O__R_E_U_S_E - _M_A_L_L_O_C__C_L_E_A_R__F_R_E_E - _M_A_L_L_O_C__C_L_E_A_R__F_R_E_E__P_A_T_T_E_R_N - _M_A_L_L_O_C__C_L_E_A_R__M_A_L_L_O_C - _M_A_L_L_O_C__C_L_E_A_R__M_A_L_L_O_C__P_A_T_T_E_R_N These are described in detail in the reference (man) page for _m_a_l_l_o_c__c_v. - 13 - 3.5 _C_h_a_n_g_e_s__i_n__t_h_e__T_e_s_t_e_r +o _C_v_c_o_v now includes a command, _o_p_t_i_m_i_z_e, that will analyze a set of tests and choose the minimum set of tests that will either have the same coverage or meet user's coverage criteria. +o Two options, ----ccccoooommmmpppprrrreeeessssssss and ----bbbbiiiittttccccoooouuuunnnntttt, have been added in _c_v_c_o_v's _r_u_n_t_e_s_t command. Option ----ccccoooommmmpppprrrreeeessssssss saves experiment database in compressed format while ----bbbbiiiittttccccoooouuuunnnntttt transforms count file into 1-bit-per-count format. +o An option, ----aaaaddddddddrrrr, has been added in _c_v_c_o_v's _l_s_b_l_o_c_k and _l_s_b_r_a_n_c_h commands to show blocks and branches by PC addresses instead of souce line numbers as default. 3.6 _I_n_t_e_g_r_a_t_i_o_n__w_i_t_h__o_t_h_e_r__T_o_o_l_s WorkShop includes facilities for integrating with other tools. The WorkShop tools can be started from other WorkShop tools by using the "Launch Tool" sub-menu under the "Admin" menu. You can add entries to the "Launch Tool" menu by adding lines to the file /_u_s_r/_l_i_b/_C_a_s_e_V_i_s_i_o_n/_s_y_s_t_e_m._l_a_u_n_c_h. The format of the entries in this file is the menu entry, followed by a comma, followed by the command line that should be run to start the tool. 3.7 _I_n_t_e_g_r_a_t_i_o_n__w_i_t_h__C_a_d_r_e__t_e_a_m_wwww_oooo_rrrr_kkkk The WorkShop "Launch Tool" menus can be combined with team_w_o_r_k's User Menus to provide a tight coupling between the WorkShop tools and Cadre team_w_o_r_k tools. 3.7.1 _S_t_a_r_t_i_n_g__t_e_a_m_wwww_oooo_rrrr_kkkk__f_r_o_m__W_o_r_k_S_h_o_p Adding the following line to the file /_u_s_r/_l_i_b/_C_a_s_e_V_i_s_i_o_n/_s_y_s_t_e_m._l_a_u_n_c_h TTTTeeeeaaaammmmwwwwoooorrrrkkkk,,,, ////ccccaaaaddddrrrreeee////ttttssssaaaa////ccccoooommmm////tttteeeeaaaammmmwwwwoooorrrrkkkk will provide an entry labeled "Teamwork" in the "Launch Tool" sub-menu of the "Admin" menu of the WorkShop tools. Selecting this menu entry will start up team_w_o_r_k. 3.7.2 _S_t_a_r_t_i_n_g__W_o_r_k_S_h_o_p__t_o_o_l_s__f_r_o_m__t_e_a_m_wwww_oooo_rrrr_kkkk Here is a sample team_w_o_r_k User Menu file for the WorkShop tools: #### WWWWoooorrrrkkkkSSSShhhhoooopppp UUUUsssseeeerrrr MMMMeeeennnnuuuu DDDDeeeeffffiiiinnnniiiittttiiiioooonnnnssss - 14 - ((((MMMMeeeennnnuuuu ((((NNNNaaaammmmeeee """"WWWWoooorrrrkkkkSSSShhhhoooopppp"""")))) ((((MMMMeeeennnnuuuuIIIItttteeeemmmm ((((NNNNaaaammmmeeee """"DDDDeeeebbbbuuuuggggggggeeeerrrr"""")))) ((((AAAAccccttttiiiioooonnnn ((((SSSSyyyyssssCCCCaaaallllllll """"////uuuussssrrrr////ssssbbbbiiiinnnn////ccccvvvvdddd"""")))))))) )))) ((((MMMMeeeennnnuuuuIIIItttteeeemmmm ((((NNNNaaaammmmeeee """"BBBBuuuuiiiilllldddd AAAAnnnnaaaallllyyyyzzzzeeeerrrr"""")))) ((((AAAAccccttttiiiioooonnnn ((((SSSSyyyyssssCCCCaaaallllllll """"////uuuussssrrrr////ssssbbbbiiiinnnn////ccccvvvvbbbbuuuuiiiilllldddd"""")))))))) )))) ((((MMMMeeeennnnuuuuIIIItttteeeemmmm ((((NNNNaaaammmmeeee """"PPPPaaaarrrraaaalllllllleeeellll AAAAnnnnaaaallllyyyyzzzzeeeerrrr"""")))) ((((AAAAccccttttiiiioooonnnn ((((SSSSyyyyssssCCCCaaaallllllll """"////uuuussssrrrr////ssssbbbbiiiinnnn////ccccvvvvppppaaaavvvv"""")))))))) )))) ((((MMMMeeeennnnuuuuIIIItttteeeemmmm ((((NNNNaaaammmmeeee """"PPPPeeeerrrrffffoooorrrrmmmmaaaannnncccceeee AAAAnnnnaaaallllyyyyzzzzeeeerrrr"""")))) ((((AAAAccccttttiiiioooonnnn ((((SSSSyyyyssssCCCCaaaallllllll """"////uuuussssrrrr////ssssbbbbiiiinnnn////ccccvvvvppppeeeerrrrffff"""")))))))) )))) ((((MMMMeeeennnnuuuuIIIItttteeeemmmm ((((NNNNaaaammmmeeee """"SSSSttttaaaattttiiiicccc AAAAnnnnaaaallllyyyyzzzzeeeerrrr"""")))) ((((AAAAccccttttiiiioooonnnn ((((SSSSyyyyssssCCCCaaaallllllll """"////uuuussssrrrr////ssssbbbbiiiinnnn////ccccvvvvssssttttaaaattttiiiicccc"""")))))))) )))) )))) By including these definitions in a user menu file, you will be able to start up any of the WorkShop tools directly from the team_w_o_r_k tools.